<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Almost done',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2018/07/29.jpg" alt="A mountain in the distance" class="framed-centred-image" width="649" height="480"/>
<section id="Minetest">
	<h2>Minetest</h2>
	<p>
		I&apos;ve defined a new flower, and I&apos;m calling it the rainbow orchid.
		It doesn&apos;t quite fit what I was after (I was trying for something more complex and with a variable facing direction), but it removes the need for strange dye drops from tree leaves.
		The flower takes on the same palette as the dye and cotton block nodes, so I can add any dye-required flower colour I&apos;m missing.
		For now, I&apos;ve decided to add rainbow orchids to the world in the eight basic colours.
		I wouldn&apos;t mind there being some sort of cross-pollination thing going on to get mixed colours as well, though those flowers will be less useful for dye-crafting.
	</p>
	<p>
		Hilariously, this change removes the need to have drops that can be counted based on colour.
		The new <code>minestats</code> functionality will no longer be in use.
		Still, it&apos;s something <code>minestats</code> always should have had, so it&apos;s not bad that <code>minestats</code> finally got fixed.
	</p>
	<p>
		The code of <code>palette</code> is now complete, though I still need to add license comments and a file crediting the textures to the places I modified them from.
	</p>
	<p>
		After leaving home for the day, I came to three important realisations about the <code>palette</code> subproject.
		First of all, I shouldn&apos;t release <code>palette</code> until <code>alchemic_palette</code>, the mod that <code>palette</code> was broken off of, is complete.
		I won&apos;t be releasing <code>alchemic_palette</code> until the rest of the Alchemy2 project (the umbrella name I&apos;m using for my efforts in getting two-item alchemy programmed) is complete so I can release them all together, but I don&apos;t need to wait until all of Alchemy2 is programmed to release <code>palette</code>.
		Just <code>alchemic_palette</code>.
		That&apos;ll give me a chance to make sure the code is stable enough to actually do pretty much its <strong>*only*</strong> job.
		Honestly, I don&apos;t think <code>palette</code> will catch on, so I&apos;m not getting my hopes up that other modders will use it as a base for their own mods.
		Still, if they do, I&apos;ll want the code stable so turbulence doesn&apos;t scare them away from integration with <code>palette</code>.
	</p>
	<p>
		Second, now that <code>palette</code> is pretty much complete, I should reverse engineer it to create an alternative mod that does the reverse.
		Instead of replacing the legacy Minetest Game dye system with something actually well-thought-out and sane, it&apos;ll allow mods built with the sane dye system in mind to function with the legacy dye system.
		This&apos;ll allow players that want to use my colourful mods to use them without overhauling the dye system if they want to.
		I think people will be more likely to use <code>alchemic_palette</code> if I don&apos;t force them to break compatibility with what they&apos;ve known for the past several years.
		Alchemy2 is my main project for right now, and it&apos;s an extension of my overall main project, <code>minestats</code>.
		<code>palette</code> is a sub-subproject.
		It&apos;s barely meaningful.
		I shouldn&apos;t let it hinder adoption of mods that would otherwise encourage the adoption of <code>minestats</code>.
		Reprogramming an alternate version of <code>palette</code> from the ground up will be worth the effort.
		That said, don&apos;t get me wrong.
		The version of <code>palette</code> that works with the legacy dye system won&apos;t give access to the full 256-colour palette.
		It can&apos;t.
		That&apos;s a major part of the reason I overhauled and replaced the legacy dye system to begin with.
		Instead, it&apos;ll provide access to the fifteen colours present in the legacy dye system.
		Colours out of range will be rounded to one of the fifteen colours by painting over those pixels on the palettes with the rounded colour in the $a[GIMP].
		Rounding will also be done any time palette indexes are calculated in code, providing better stackability.
		In fact, the fact that the actual palette image has been modified won&apos;t even matter unless someone tries to cheat a coloured item of a specified colour in or they load the reversed version of the mod into a world that previously used the original version.
		The only reason the palettes need to actually be modified is to eliminate loopholes.
	</p>
	<p>
		Third, while wool replaces cotton block nodes and legacy dye replaces palette-based dye in the reversed mod, there exists no replacement for the orchid node, because the orchid node serves a new purpose instead of replacing something outdated in Minetest Game.
		It therefore can&apos;t be reversed.
		On a surface level, this means the orchid should be broken off into its own mod because mods depending on <code>palette</code> can&apos;t depend on the flower existing.
		Unless it&apos;s in a separate mod, there&apos;s no way to have the flower be a dependency of another mod, such as one that tries to craft something out of it.
		On a deeper level though, it shows the flower doesn&apos;t really belong there in the <code>palette</code> mod to begin with.
		<code>palette</code> has a very specific purpose, and while the orchid supports that goal, it isn&apos;t a part of that core utility.
		Even if I change my mind and don&apos;t end up finishing the reversed <code>palette</code> mod, the orchid needs to go.
		I also think maybe the orchid should be replaced by four flowers with differing shapes, one of each magenta, cyan, black, and green.
		I&apos;ll take the green and black flowers from the unstable version of Minetest Game, and explain in the code and the write-up that I&apos;ll remove them once the stable version of Minetest Game catches up.
		Seriously, I&apos;m confused as to why those flowers didn&apos;t make it into this last stable version.
		They were already in the working branch at that point.
	</p>
	<p>
		You know what?
		No.
		I changed my mind.
		I don&apos;t want to waste time reverse engineering my reverse <code>palette</code> mod to create the most accurate compatibility palette I can.
		After spending about an hour thinking about how to best get the seven non-basic legacy colours into the 32-colour palette such that they&apos;d line up with approximations from the full <code>palette</code> mod and getting nowhere, I realised the futility.
		There are better approximations outside the 32-colour range, but I needed them in the 32-colour range because they&apos;ll fit there and some nodes only use a 32-colour palette.
		However, there&apos;s no need for me to try to make the two versions of the palette even close to mirror each other.
		If a world switches dye systems, things are already going to break.
		The legacy system was so bonkers that I had to break compatibility with it entirely to have any chance of cleaning it up.
		Any compatibility saved through palette estimation will be for nothing due to the more basic stuff breaking so badly.
	</p>
	<p>
		Realising that, I figured I&apos;d just put the fifteen legacy colours into the first fifteen slots on the palette.
		It&apos;d be clean and easy, and I was already planning to fix the rest in code.
		The rest of the palette would just be blank.
		However, I then realised people would likely use my hard work not as intended, but as a library for defining their own nodes based on the legacy colours.
		They wouldn&apos;t use it as a fallback for people that didn&apos;t want to upgrade, but as a way to encourage people <strong>*not*</strong> to upgrade!
		If people want to discourage upgrading, so be it, but I shouldn&apos;t waste my own efforts fighting against my own cause.
		I&apos;m back to forcing users to upgrade if they want to use my coloured nodes, I guess.
		The section of the Alchemy2 project that involved coloured nodes is its own mod though, so it&apos;d be easy to install the rest of Alchemy2 and leave out the sticky part.
		For that matter ...
		What if instead of making an alternate version of the <code>palette</code> mod that allows palette-based nodes to act like they&apos;re using the legacy multi-node-definition system, I made an alternate version of <code>alchemic_palette</code> that <strong>*actually*</strong> uses that system?
		There&apos;d be so many node definitions.
		So many nodes.
		It&apos;d really highlight the problem, using the problem itself.
		It&apos;d function <strong>*exactly*</strong> like the system used by Minetest Game.
		There could be no complaining, especially given that I&apos;d also provided a better solution.
		You can use the old system or the new one.
		It&apos;s your choice.
		Just don&apos;t expect a hybrid.
		Defining crafts would be a million times easier, too.
		In fact, it&apos;d be easier to build than the sophisticated code I developed for <code>palette</code>.
		I think that&apos;s what I&apos;ll do.
		I&apos;ll build two versions of <code>alchemic_palette</code>.
	</p>
	<p>
		There is no way to win though.
		Even this has its problems.
		Other mod developers might rely on these legacy-imitating nodes in their own mods.
	</p>
</section>
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		My discussion post for the day:
	</p>
	<blockquote>
		<p>
			That sounds a lot like me, actually.
			I frequently daydream, especially during my commute to and from work.
			I&apos;ve done it all my life though, and used to do it on the way to school and when going on car rides.
			I make up elaborate stories that tend to interrelate along a longer period of time, every once in a while throwing out my character and starting fresh.
			I really should write some of these down stories, but I&apos;m not so good with words.
			Also, who even has the time?
		</p>
	</blockquote>
</section>
END
);
